Transfer length for content-encoded objects, via EXT_FTI - #90

…file allows it

Problem
  Under the MBMS Download Profile a content-encoded object could not be decoded
  by any receiver. Observed live: a gzip object transmitted and received on
  loopback ends "Decompressed length does not match expected Content-Length"
  and the object is discarded. The FDT parser on this base already declines to
  substitute Content-Length for an absent Transfer-Length once an encoding is
  applied, which is correct, but nothing then supplies the real length and three
  things stand in the way:
   - reception was started for an object whose length the FDT never stated, so
     the object was partitioned to a length that was simply not known
     (src/Receiver.cpp);
   - adopt_fdt_metadata() took neither Content-Encoding nor Content-Length from
     the FDT entry, so an object whose reception bootstrapped from EXT_FTI was
     delivered still compressed and then length-checked against the encoded size
     (include/File.h);
   - and the sender put EXT_FTI on the FDT packet only, gating both extensions
     behind "if (toi == 0)", so the one permitted route for the transfer length
     carried nothing (src/AlcPacket.cpp).
  [observed, code-derived]

Basis
  The profile obliges a receiver to handle these objects.
  TS 26.346 V18.2.0 clause L.4.2, second list: "Content-Encoding set to 'gzip'"
  is the single item of the list introduced as "may be carried in the FDT sent
  by the FLUTE sender, and shall be supported by the FLUTE receiver".
  It also forbids the attribute that would state the length.
  TS 26.346 V18.2.0 clause L.4.4, fourth list: "The following attributes shall
  not be carried in the FDT sent by the FLUTE sender:", Transfer-Length first.
  And Content-Length may not stand in for it here.
  RFC 3926 clause 3.4.2: "If the file is not content encoded before transport
  (and thus the "Content-Encoding" attribute is not used) then the transfer
  length is the length of the original file, and in this case the
  "Content-Length" is also the transfer length."
  That leaves the object's own EXT_FTI, which every receiver must support, and
  reaching for it departs from a "should" rather than a "shall not".
  TS 26.346 V18.2.0 clause L.4.7: "FEC Object Transmission Information in FLUTE
  packets which carry symbols of content files should be conveyed by the
  FEC-OTI parameters in the FDT". Every FEC-OTI parameter the profile permits is
  still in the FDT; only the transfer length travels in band.

Raised by
  a maintainer's direction that the 3GPP receive path be specification
  compliant, which turned a recorded stop-and-ask into a decision

Change
  The receiver defers starting an object whose length the FDT does not state,
  takes it from the object's EXT_FTI when the first packet arrives, and adopts
  the waiting FDT entry immediately so the object still lands at its
  Content-Location and is decoded per its Content-Encoding.
  adopt_fdt_metadata() now carries Content-Encoding and Content-Length across
  while still leaving fec_oti to the in-band value. The sender emits EXT_FTI on
  a content packet exactly when the FDT cannot state the length, which under
  this profile is a content-encoded object and nothing else. Also corrects the
  comment beside the sender-side prohibition, which claimed nothing is lost by
  withholding Transfer-Length; that holds only for an unencoded object.

Verification
  T1: EncodedObjectTransferLengthTest, 3 new cases covering the substitution
  rule in both directions and an explicit Transfer-Length overriding both;
  whole suite 64 cases passing.
  T2: live over real multicast. A gzip object is received byte-identical,
  sha256 a4366ca61727259f94ba..., the same digest as that object sent
  uncompressed. The identical run discarded it before this change. An
  uncompressed transfer still arrives byte-identical.

Not in this change
  Emitting Transfer-Length in the FDT, which clause L.4.4 forbids.
  The FDT parser's substitution rule and the decompression path itself, both of
  which are already on this branch's base.